Subject: Accounting at ANR nodes

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Wed, 3 Apr 96 11:53:25 EST

Jim,

What an interesting idea.  I can't think of any architectural problems,
but it might be costly from an implementation standpoint - performance
and storage implications of large tables and large ANR labels, algorithms
for assigning and reusing labels, running out of labels, race conditions
involving label reuse, effect on network management...  And then how
would you collect the accounting statistics - a MIB change perhaps?  An
implementer should probably total up the cost of these and other
implementation details, then analyze it from a cost/benefit standpoint.
There might be some new network management architecture too.

Other thoughts?

Marcia

---

From: "jim (j.) cobban" <[email-masked]>
Date: Wed, 3 Apr 1996 21:34:00 -0500

>and storage implications of large tables and large ANR labels, algorithms

One ANR label per route is a worst case, and a simplification of the
architecture.  In the case of the customer example I used in my note there
are three tariff classes which need to be distinguished.  This could be
handled by assigning a maximum of three ANR labels per TG, with each route
setup selecting the appropriate label for the tariff class, which is
identified by some algorithm applied to the RSCV.  However the network
service provider wants to be able to assign back costs to individual
customers.  Having a separate ANR label for each route, and then identifying
the owner of the end-points of the route at route setup time, permits a
bill-back for network resource usage.

Other optimizations include not turning this support on in all nodes.  For
example knowing that I have three tariff classes I might arrange that this
accounting collection is only performed on nodes which handle international
or intercontinental traffic.  This is analogous to how the phone companies
bill for calls.  Long distance calls are routed through special nodes which
perform the accounting, while local calls are "free" because they are not
routed through such nodes, and therefore no accounting records are cut for
them.

>involving label reuse, effect on network management...  And then how

The HPR architecture already worries about reusing labels in section 7.1.3.

>would you collect the accounting statistics - a MIB change perhaps?  An

The conclusion of the HPR MIB discussion at AIW 10 was that we did not have a
HPR MIB, in that the NCL table structure was only suitable for the 6611.  As
we considered options, we had to fall back on what information was actually
available to an ANR only node as guaranteed by the HPR architecture. 
Therefore we concluded that in some form the HPR MIB can, at most, have a
table which is indexed by ANR label and contains priority based
statistics for the NLPs which were processed on that label.  Since we do not
currently have an HPR MIB, only a draft on which we have a rather shaky
approved direction status, we cannot "change" it, technically.